home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Skunkware 5
/
Skunkware 5.iso
/
man
/
cat.6
/
recover.6
< prev
next >
Wrap
Text File
|
1995-07-25
|
6KB
|
133 lines
RRRREEEECCCCOOOOVVVVEEEERRRR((((6666)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((9999 JJJJaaaannnnuuuuaaaarrrryyyy 1111999999993333)))) RRRREEEECCCCOOOOVVVVEEEERRRR((((6666))))
NNNNAAAAMMMMEEEE
recover - recover a NetHack game interrupted by disaster
SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS
rrrreeeeccccoooovvvveeeerrrr [ ----dddd _d_i_r_e_c_t_o_r_y ] _b_a_s_e_1 _b_a_s_e_2 ...
DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN
Occasionally, a NetHack game will be interrupted by disaster
when the game or the system crashes. Prior to NetHack v3.1,
these games were lost because various information like the
player's inventory was kept only in memory. Now, all
pertinent information can be written out to disk, so such
games can be recovered at the point of the last level
change.
The _b_a_s_e options tell _r_e_c_o_v_e_r which files to process. Each
base option specifies recovery of a separate game.
The ----dddd option, which must be the first argument if it
appears, supplies a directory which is the NetHack
playground. It overrides the value from NETHACKDIR,
HACKDIR, or the directory specified by the game
administrator during compilation (usually
/usr/games/lib/nethackdir).
For recovery to be possible, _n_e_t_h_a_c_k must have been compiled
with the INSURANCE option, and the run-time option
_c_h_e_c_k_p_o_i_n_t must also have been on. NetHack normally writes
out files for levels as the player leaves them, so they will
be ready for return visits. When checkpointing, NetHack
also writes out the level entered and the current game state
on every level change. This naturally slows level changes
down somewhat.
The level file names are of the form base.nn, where nn is an
internal bookkeeping number for the level. The file base.0
is used for game identity, locking, and, when checkpointing,
for the game state. Various OSes use different strategies
for constructing the base name. Microcomputers use the
character name, possibly truncated and modified to be a
legal filename on that system. Multi-user systems use the
(modified) character name prefixed by a user number to avoid
conflicts, or "xlock" if the number of concurrent players is
being limited. It may be necessary to look in the
playground to find the correct base name of the interrupted
game. _r_e_c_o_v_e_r will transform these level files into a save
file of the same name as _n_e_t_h_a_c_k _w_o_u_l_d _h_a_v_e _u_s_e_d.
Since _r_e_c_o_v_e_r must be able to read and delete files from the
playground and create files in the save directory, it has
interesting interactions with game security. Giving
ordinary players access to _r_e_c_o_v_e_r through setuid or setgid
Page 1 (printed 7/7/95)
RRRREEEECCCCOOOOVVVVEEEERRRR((((6666)))) UUUUNNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((9999 JJJJaaaannnnuuuuaaaarrrryyyy 1111999999993333)))) RRRREEEECCCCOOOOVVVVEEEERRRR((((6666))))
is tantamount to leaving the playground world-writable, with
respect to both cheating and messing up other players. For
a single-user system, this of course does not change
anything, so some of the microcomputer ports install _r_e_c_o_v_e_r
by default.
For a multi-user system, the game administrator may want to
arrange for all .0 files in the playground to be fed to
recover when the host machine boots, and handle game crashes
individually. If the user population is sufficiently
trustworthy, _r_e_c_o_v_e_r can be installed with the same
permissions the _n_e_t_h_a_c_k executable has. In either case,
_r_e_c_o_v_e_r is easily compiled from the distribution utility
directory.
NNNNOOOOTTTTEEEESSSS
Like _n_e_t_h_a_c_k itself, _r_e_c_o_v_e_r will overwrite existing
savefiles of the same name. Savefiles created by _r_e_c_o_v_e_r
are uncompressed; they may be compressed afterwards if
desired, but even a compression-using _n_e_t_h_a_c_k will find them
in the uncompressed form.
SSSSEEEEEEEE AAAALLLLSSSSOOOO
nethack(6)
BBBBUUUUGGGGSSSS
_r_e_c_o_v_e_r makes no attempt to find out if a base name
specifies a game in progress. If multiple machines share a
playground, this would be impossible to determine.
_r_e_c_o_v_e_r should be taught to use the nethack playground
locking mechanism to avoid conflicts.
Page 2 (printed 7/7/95)